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Exploratory Application Development Using Smalltalk 


ABSTRACT 


Smalltalk is proving to be an important tool for application and prototype 
development. Smalltalk, both a language and an environment, is condu- 
cive to the exploration and development of computer applications. The 
language is object-oriented, programming involves the creation of short 
self-contained methods for altering objects within the system. These 
methods are easily refined as understanding of the application increases. 


Also, the environment provides extensive support for program 
development. Objects exist within a class hierarchy which allows a pro- 
grammer to borrow and refine existing code for use in new applications. 
Smalltalk has specialized windows that allow the user to examine and 
modify existing code, examine and alter data structures, or interrupt and 
examine computations. 


The benefits of using Smalltalk are discussed and related to a number 
of projects currently under development at Tektronix. 
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implementation and allowed to approach the essential concepts of the application 
independently. 


Modularity limits interactions of methods. Methods are developed and debugged 
individually, then compiled into byte code. When the program is executed, an interpreter 
looks up and executes each appropriate method. Because of this independence of 
methods, the programmer can modify any method at any time. As long as a method 
does not change the fundamental nature of an object, it can manipulate that object in 
harmony with any other method designed for that object. In fact, code composing a 
method can be radically changed without affecting the behavior of other methods. This 
allows a programmer to rapidly alter the operation of a system as the requirements 
change. 


12 Smalltalk programming is only a refinement. 


Smalltalk speeds development by allowing the reuse and refinement of previously 
developed methods. This is accomplished through the class hierarchy inherent to 
Smalltalk. Every Smalltalk object is a member of a particular class, and every class is a 
subclass of another class (except for the class Object which is the most basic type of 
object). By making one class a subclass of another class, the programmer states that the 
subclass will inherit all the properties of the superclass, unless explicitly stated otherwise. 


To create a Smalltalk program, one must identify new classes of objects necessary 
for the task. Then one must discover how these new objects are similar to objects defined 
by an existing Smalltalk class. If the programmer can find a similar class to the new one 
it provides a boon - the code from the old class is likely to perform most of the needed 
operations of the new class. 


If abstractions are made properly it can significantly reduce the amount of effort 
necessary for development. Subclassing saves effort because commonly used methods 
can be stored at their highest level of abstraction, and are then defined for all subclasses. 
For example, some methods defined for Collection suffice for all subclasses of Collection 
- such is the case for isEmpty. Other methods defined for Collection suffice for some but 
not all of its subclasses. select: is a means for picking an object out of a collection, and is 
defined in Collection. Most subclasses of Collection use this select:, however, Set, Diction- 
ary, OrderedCollection and SortedCollection redefine select: to better fit their unique 


features. 


To acheive the proper level of abstraction for a Smalltalk program one needs a very 
accurate and complete articulation of the task at hand. Often, when developing a new 
application, such articulation is not possible. Usually a programmer will struggle to solve 
a problem only to later find a solution written by a previous Smalltalk programmer. 
However, it is very easy to implement a system with current understanding and then 
refine it to create more elegant implementations. 


13 The environment İs tuned for development. 


There are many valuable tools designed to aid the user in the development of an 
application. The three most valuable Smalltalk tools are the code browser, the data 
inspector, and the debugger. 


The browser is a structured means to access and create Smalltalk code. The 
browser provides categorized access to any code in the system, helping the user with the 
location of useful classes and methods. Furthermore, the browser provides the means to 
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make queries about classes and methods. For example, one can ask to see all of the 
methods that use a given method or to examine the hierarchy of a class. Finally, the 
browser provides templates for the creation of new classes and methods. 


= Data inspectors are very useful for examining the data structures that define an 
object. With an inspector, the programmer may examine and alter any object in 
Smalltalk. This proves useful in examining objects at various points within a computation 
to detect the source of errors. In addition, new values can be injected into an object to 
create a new object or to experiment with the effects of such a change. 


The debugger allows a user to examine code that has been interrupted. The 
debugger presents the execution stack, and highlights the portion of code that was being 
executed at the time of interrupt. The debugger preserves the context of the code and 
allows the user to evaluate expressions within that context. The debugger includes data 
inspectors on local variables and instance variables relevant to the method. This tool 
helps the user form a clear picture of the state of the computation at the time of inter- 
rupt. In addition, it allows experimentation with new code in the context at the time of 
interrupt. 

- Other than these three tools, the user can exert substantial control over the develop- 
ment environment. Any portion of the environment is accessible and modifiable by the 
user. For example, Steve Messick and Kent Beck of our lab needed to examine variables 
as they were being altered by a program. With some additions to the Smalltalk inter- 
preter, they created active variables, variables which indicate when they are accessed 
(Messick and Beck, 1985). By the creation of such variables, it was possible to construct 
gauges for monitoring the variables, as was done with LOOPS (Stefick, Bobrow, Mittal 
and Conway, 1983). 


14 Graphics are simple 


Graphics are an integral component of Smalltalk. The creation of graphic displays 
is simple and natural, making the system ideal for implementing and experimenting with 
arbitrary user interfaces. 


Using Smalltalk, it is very easy to create display windows that illustrate aspects of 
the data under consideration. Smalltalk windows are Model-View-Controller (MVC) 
triads. To create a new type of window, the first step is the creation of the model which 
can be any object, such as a number, a string or a bit map. 


Suppose we have an Integer serving as a model. The class Integer defines the opera- 
tions that can be performed upon the object, but not the ways to display it on the screen. 
To view the number, we need to define ways of displaying the information in the model, 
and ways of communicating with the model: these are the function of the view and con- 
troller respectively. Any model can have multiple View-Controller pairs, each defining a 
different way of displaying and communicating with the model. Though it is not simple 
to understand and use MVC triads, they provide an elegant framework for the creation 
of new user interfaces. With experience, a programmer can generate interfaces to match 
the needs of any application. The speed with which these may be developed makes it 
very easy to experiment with new Human-Computer interfaces. 
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2. Smalltalk as a communication tool 


The ease of program development and the form of the resulting programs allows 
Smalltalk to be used as a tool for communicating. 


Traditionally, new software projects have been developed in a static, Paper environ- 
ment. A project designer begins with a concept and generates a design. This design has 
usually been prepared as written text, describing the functions and operation of the 
future project. Such a static development process depends upon the vision of the 
engineer, who the cannot possibly consider all of the implications, problems or opportun- 
ities that may present themselves in the development of a system. 


Rapid prototyping avoids traditional design problems by permitting design through 
exploration and experimentation. An application can be developed by creating the 
appropriate objects and data structures and experimenting with them. It is easy to build 
an application piece by piece as needs are perceived and addressed. Often, one can 
develop an application from existing classes of objects. Methods are then created to 
orchestrate operations upon those objects. Various implementations of parts of the pro- 
gram may be switched in and out to determine the optimal means for accomplishing 


tasks. 


What is the result of this fluidity of code? As a concept is generated, it is very easy 
to create a prototype to match that concept. Creation of a Smalltalk prototype has four 
benefits: 


© design problems become explicit: many of the unexpected problems for a design will 
appear in the prototype. 


© unexpected opportunities may emerge: in a design there may be valuable opportunities 
that were not originally considered. 


© ideas can be communicated: the prototype may be the best way of explaining to oth- 
ers how a system will work. 


© prototyping highlights the design: The result of a prototype is the object structure and 
methods. Each of the methods will serve as a very precise description of how the 


system will operate. 


Smalltalk programs are an easy way to communicate, and enhance ideas. About a 
year and a half ago, I was called upon to build a prototype of a Troubleshooting Assis- 
tant - an expert system designed to aid inexperienced troubleshooting technicians repair 
Tektronix equipment. The result was the FG502-TASP (Alexander and Freiling, 1984a, 
1984b). In a period of months we developed an expert system and interface to demon- 
strate a concept we had been promoting for six months. The reaction to the prototype 
was immediate. For the first time, people were able to see what our system would do, 
and understand the implications of the technology. 


There was another benefit of building this prototype as well. We discovered the use- 
fulness of simple graphics to the technician. In reading schematics, a technician has to 
identify where a part may be on the circuit board. This is a time consuming job. Without 
thinking much about it, we put a graphics interface into the system by which a user can 
browse a circuit and find these cross-references simply by pointing to a component and 
clicking a mouse button. The effect of this user interface was startling. Besides the fact 
that this brought the demonstration program to life,* it illustrated how simply an 


“In fact it had an unfortunate side effect of giving the illusion of completeness. We had many people 
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important problem can be solved. For some viewers of our system, the part cross- 
referencing was more important than the troubleshooting component! 


Without Smalltalk, we would not have added this interface, and we would not have 
recognized the important effect such a straightforward addition could have for our sys- 
tem. The important lesson we learned was that the interface can overshadow any techni- 
cal excellence that might have been exhibited by the expert system. 


A Smalltalk prototype can serve as a document for the communication of ideas. 
Typically, when a Smalltalk program is written the methods are small and specific. So, 
when you examine Smalltalk code it is easy to identify the essential fragments of the pro- 
cess being developed. Once a prototype exists, it is simple easy to examine the code and 
identify the functions that are essential to the application. 


3. Some applications with Smalltalk 


In the couple of years that Smalltalk has been available within Tektronix, a number 
of users have adopted it as the language of preference. Below some example applications 
are described briefly to highlight how Smalltalk can be used and features of Smalltalk 
that facilitated the work. 


3.1 Symbolic Algebra (Research of Guy Cherry) 


:This project has been building a system to perform symbolic computations much 
like Reduce or MACSYMA. The development involves defining a means for performing 
operations upon symbolic objects. For example, one might want to add a pair of polyno- 
mials for later evaluation. 


“Development of a symbolic algebra system involved the creation of new classes of 
objects, each representing a specific algebraic structure. These classes each needed 
methods for operations such as addition and subtraction. Many algebraic structures share 
properties with other algebraic structures, and were defined in the class hierarchy to 
exploit these similarities. For example, all algebraic structures are a refinement of the 
Smalltalk class Set. Monad defines the most general of the algebraic structures, and is a 
subclass of Set. Polynomials are a more specific class and are farther down the hierarchy, 
but still inherit methods from Set. For example, the concept equals is pivotal, and 
needed to be redefined for each algebraic construct. However, it was possible to define 
notEquals as a completely general method of Set and is used by all subclasses. The ability 
to define methods at the highest level of abstraction proved to be very valuable in the 
formal definition of the system. 


- In some cases, there was more than one class resembling a to-be-created class. Such 
is the case for Integer* which is both an OrderedSet and a Ring. One add-on feature of 
Smalltalk provides the capability for multiple inheritance hierarchies. By making 
Integers a subclass of both OrderedSets and Rings, the new class was able to take on the 
properties of both super classes. 


asking when our (far from complete) prototype would become a product. 


“Integer is normally defined in Smalltalk, but the original definition was not suited for a formal symbolic 
algebra system. Consequently, a new Integer was defined for use in the symbolic system. 
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3.2 Program animation (Research of Ralph London and Rob Duisberg) 


The focus of this project is to discover methods of graphically animating the opera- 
tion of algorithms and programs (London and Duisberg, 1984). The goal is to allow a 
user to animate a program with only minimal alterations to the code. Figure 1 shows a 
sample animation of a program to solve the producer-consumer problem. The producer 
and consumer are each represented as a rectangular region which produces or consumes 
data lozenges. When one is produced it passes through the monitor, and is placed into a 
circular queue. When something is consumed, it goes from the queue through the moni- 
tor to the consumer. With this illustration it is very easy to see and understand the opera- 
tion of the algorithm. 


Code that monitors the operation of the program guides the display ond movement 
of these forms on the display. The Smalltalk graphics made this project feasible. Anima- 
tion was easily created by generating bit-map forms for parts of the diagram such as the 
queue or the data lozenge. By displaying and redisplaying the forms it is possible create 
the illusion of data motion. 


Of greater interest is the means by which the animated program is monitored. One 
of the goals of the project was to create animation tools that would allow animation of a 
program with minimal modification of the program itself. This involved the customiza- 
tion of the operation of the MVC triad. Basically, the controller was modified so it had 
intimate control of the view as it relates to the model (in this case the program under 
animation). The open accessibility of the code defining MVC triads made a difficult pro- 
ject feasible. 


33 Knowledge collection (Research of Mike Freiling, Brian Phillips, Steve Messick, Shel- 
don Nicholl, and Jim Alexander) 


The INKA (JNglish Knowledge Acquisition) system was developed in an effort to 
facilitate expert system development (Phillips, Messick, Freiling and Alexander, 1985). 
The system provides a means for an expert to construct statements about diagnosing elec- 
tronic equipment failures. A Smalltalk interface guides the construction of these state- 
ments and translates them into Prolog clauses. An inference engine written in Prolog 
interprets these Prolog clauses and communicates results to the user. A rule generation 
example is presented in Figure 2. 


This project benefited from a number of interface features of Smalltalk. Collection 
of statements required a means of capturing keystrokes and mouse actions very different 
from the normal Smalltalk capabilities. However, it was a small task to identify the con- 
trolling portions of Smalltalk windows, and refine their operation for INKA purposes. 
Likewise, the system communicated with the user by placing probe icons on the map of 
a circuit board to indicate measurement locations. Here, too, the construction of a highly 
graphic user interface greatly enhanced the system. 


An integral part of this system is a natural language interface, called INGLISH 
(Phillips and Nicholl, 1984). INGLISH uses a left-corner predictive parser which gen- 
erates the set of possible continuations of a statement in formation. One of the problems 
of parsing is the propagation of multiple potential parses of a statement. In a functional 
language, this involves creating large data structures (iz., a linked list) which must later 
be processed to find the correct parse. With Smalltalk, it was possible to generate a sin- 
gle object for each potential parse. These objects were held in a queue. When new ele- 
ments were added to the statement, the change was broadcast and each object would 
update itself. The bookkeeping and structure of the data was handled entirely by existing 
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1. A Smalltalk animation of the producer-consumer problem (from London & 
Duisberg, 1984). p: 


F THE VOLTAGE OF NODE 4 IS EQUAL TO THE VOLTAGE OF NODE 5 THEN RESISTOA 2 HAS FALED . **PARSED 
rue(comp(eqvoltage(node(4))voltage(node(5)))status(component{resistor(2)} faled) =} 


DMPEDANCE (s6, 
tS (#7) 


(#y) 

PHASE (#10) 

POWER (#11) 
RESISTANCE (#12) 
VOLTAGE (#13) 

**ABORT (#14 


is led number 2 not flashing? yes 
What is the voltage of node number 27 15 
ts led number 1 dm? no 


is it true that the voltage of node number 4 is equal to the voltage of node 
mmber 57 yes 


OscHator number 1 ls falling 
Resistor number 2 is faling 


Hoooonooooo; 

DoOoononoeeS : ' 

ponnpono ifs, Nadit h et a d d d a Dd d d 

ODooooo0n ADOoSeoHsoal 

Oooooocoe ni JI Oondoogoop on 
DODoSeoog yy Se" AOCOoOoOOoooL 
OONOCOOG e 'aorrnnsoo 
ooponogoo8'|«: Oy fs, 

nooon0o4.- x 

DOOOOOOG: i.. opocooosgoo 
OOODOOODE fin OBOODSooooE 


lebebeb ol Bel ' -5> 





Figure 2. Creation of a rule using INKA. The INGLISH window shows the creation of 
the rule. The prolog window show an example consultation. The Instrument Data win- 


dow shows the graphical interface. 


Smalltalk code. 


Another component of INKA benefited from the use of an object oriented 
language. Parsed sentences were translated into Prolog clauses using functional schemata, 
as in a Lexical-Functional Grammar. Fortuitously, the functional structure generated by 
this technique was simple to represent in objects. Each functional structure was com- 
posed a set of key values representing components of a statement. The creation of 
objects resembling these functional structures made it simple to represent and manipulate 
the parsed statements, and later generate appropriate Prolog clauses. 


34 Prolog interface experiment (Research of Kent Beck) 


In an effort to experiment with user interfaces for Prolog, a basic Prolog interpreter 
was constructed in Smalltalk. The implementation of a Prolog interpreter in Smalltalk 
was simplified because many elements of Prolog could be defined in an object-oriented 


style. 


Prolog clauses were constructed as single objects, containing other objects to 
represent the head, tail and variables of the clause. The execution of a Prolog statement 
may be conceptualized as a large proof tree, with each node in the tree representing one 
particular step in the proof. In Smalltalk, this tree was represented as a set of activation 
records. For each Prolog proof step, an activation record is generated. The activation 
record is an object containing the clause under consideration, current variable bindings, 
and the child activations necessary to to prove the clause. Using this approach a viable 
Prolog was constructed in a couple of months and allowed research on Prolog user inter- 
faces to get started quickly. 


35 IC Design Tool (Research of Mike Miller, Steve Vegdahl, Chan Lee, and Ward Cun- 
ningham) 

This project’s goal was to prototype a method for generating IC designs. For the 
purposes of this paper, the most interesting aspect of this project is the way Smalltalk was 
used in a group development effort. The IC design tool was composed of three indepen- 
dent parts: a functional design component, a place and route component, and a compiler 
design component. Each component was developed as a separate project with little 
regard for the other components. In fact, all three projects were already under develop- 
ment before the design of the IC tool was determined. 


The projects were merged through the definition and creation of an object-oriented 
database. This database was designed to serve as the communication interface for the 
components. For integration, each of the developers was required to define methods per- 
miting his component to communicate with the interface. Thus, once the object-oriented 
database was defined, the three components did not have methods for communicating 
with each other, only with the database. | 


The result was that three largely independent projects were unified in a period of 
days. Each researcher was free, during the development period, to explore and develop 
ideas without the restriction of requirements or specifications. Yet, Smalltalk allowed the 
rapid union of these research efforts to form a useful design tool. 
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4. Drawbacks to Smalltalk 


Smalltalk is not a panacea. In fact, many of the current users at Tektronix curse it 
continually (though they cringe at the thought of returning to another language). Many 
of the problems are not unique to Smalltalk, but should be mentioned for completeness. 


4.1 Problems with learning Smalltalk 


First of all, Smalltalk can be difficult to learn. We have found that new users get 
very excited about the language for the first few days. It has very powerful features 
which allow a new user to do things beyond the capabilities of another language. How- 
ever, the initial euphoria is often followed by a disillusionment. This may be due to the 
fact that users are seduced into projects far beyond their abilities (in Smalltalk or any 
other language) and try things they wouldn’t otherwise consider. 


A beginner rarely understands the nature of object oriented programming. Of 
course, it is possible to program Smalltalk as if it were LISP or C, and inexperienced 
programmers often do this. The symptom is long methods resembling procedural code. 
The new programmer must learn how to break a project into appropriate objects and 
assign appropriate methods to each object. 


. .To use Smalltalk effectively, the new user must learn the basics a vast number of 
object classes. This is necessary to effectively use the inheritance hierarchy. Such ability, 
though, can only come with time and experience. 


Finally, there is. a. drawback to the extreme modularity of the programming 
language. By breaking up the steps, it becomes very difficult to follow the flow of con- 
trol in some applications. As a result it is often very simple to identify what a method is 
doing, but harder to understand exactly how that is being accomplished. 


42 Problems with development 


Smalltalk was originally designed to operate on single user systems and this leads to 
some development problems. Remember that the Smalltalk system is highly customiz- 
able, allowing a user to mold the system to his or her particular needs and preferences. 


Repeatedly, we have run into situations where a user has needed a special function 
(say a special function for a Collection) and proceeds to create a new method. Much 
later, that user uses the new method to build an application useful to others. When this 
new application is distributed, the developer must be careful to also distribute all the per- 
sonal methods he or she has developed. Often, however, this is not done and the distri- 
buted code will not work. 


...... The problem is not serious, but is annoying when encountered. This has lead to the 
first maxim of Smalltalk programming: 


@ Don't modify classes that you didn’t write 


Instead, the safest practice is to create a new class when you perceive a deficiency in an 
existing class. Thus, when the programmer finds a problem with Collection, it would be 
better create a new class as a subclass of collection, and add the new method there. 


Beyond the alteration of classes, there are other problems which prevent smooth 
distribution of code. Many times the interactions of system components will not operate 
properly. An example is the windowing system. Say that user Y has modified his win- 
dowing so that the windows are updated differently. Also, user Y has developed a tool 
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that he distributes to other users. When user Z reads the new code into her system, she 
finds the tool won’t work because of the way it interacts with the window updating. This 
suggests a second maxim: 


e periodically try new code in a clean system image 


This way the user can ensure that the new code will work in the original Smalltalk 
image, and should work in most other Smalltalk images. If it doesn’t work in another 
image, it is the result of a change made by the image owner. 


A third problem results from the persistence of objects in a system. Often one will 
create a data structure. With the debugging tools, it is easy to change the object rather 
than doing so with methods. The result is that when the system is finished and contains 
important data objects, the developer may not have the tools to construct it a second 
time. In one instance, we were developing an application for a demonstration. We con- 
structed the data structure, and methods to operate on it simultaneously. However, in 
debugging, the object was often modified from the debugging environment. This was fine 
in that it speeded development, and the demonstration was completed when we needed 
it. But later, when we decided to build a second similar application, we found that there 
was no code for creating the appropriate data structure, and it was difficult to remember 
how to build it. This generates a third maxim: 


è Ensure that the code for creating the object is in sync with the code for operating 
the object. 


By making sure of this, one will avoid problems with replicating the work building up the 
data structure. 


5. Summary 
Smalltalk is conducive to rapid, exploratory development of new applications. This 


is due to the object-oriented foundations of the language and the tight integration of the 
development environment with the language. 


Exploratory development of programs is useful for the accurate articulation of 
ideas, as well as the documentation of their possible implementation. Through the 
development of prototypes it is feasible to communicate accurately and graphicly the 
potential of a new application. 
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